NetNews Offline 2

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part2 / 11826 < prev next >

Wrap

Internet Message Format | 1996-08-05 | 29.6 KB

Path: news.aimnet.com!news From: JNavas@NavasGrp.com (John Navas) Newsgroups: comp.dcom.modems Subject: The Navas 28800 Modem FAQ - 2/6 Date: Sun, 21 Apr 1996 17:27:26 GMT Organization: The Navas Group of Dublin, CA, USA Message-ID: <317a6fc7.61936148@news.aimnet.com> NNTP-Posting-Host: dial-bp1-2.iway.aimnet.com X-Newsreader: Forte Free Agent 1.1/16.198 <<cont>> What's wrong with my dialup SLIP/PPP connection? Make absolutely sure that there is one and only one WINSOCK.DLL on your system, and that it is the right one. Make sure that the directory (e.g., C:\TRUMPET) for your dialup SLIP/PPP package (e.g., Trumpet Winsock, aka TCPMAN) is in your DOS PATH environment variable. Try the following settings in your dialup SLIP/PPP package: For true PPP or SLIP: TCP MSS: 536 MTU: 576 [MSS + 40] TCP RWIN: 2144 [MSS x 4] (For reference see RFC 879[146]) Note: Increasing RWIN to larger multiples of MSS (e.g., 2680, 3216, 3752, or 4288) may improve performance a bit on sluggish links. For TIA Pseudo-SLIP (see comments on TIA below): TCP MSS: 1460 MTU: 1500 [MSS + 40] TCP RWIN: 4096 (For reference see "Installation Instructions for Single-User TIA[147]") For more SLIP/PPP help see "Any Trumpet Winsock tips?[148]" and "Troubleshooting Reference[149]." Note: There is no significant performance difference between SLIP and PPP. (See "SLIP vs PPP Performance Comparison[150]" and "Performance Issues[151]") The author recommends the following Winsock applications (all of which are freeware or shareware): Dialup TCP/IP (SLIP/PPP) stack: Trumpet Winsock (See Any Trumpet Winsock tips?[152]) (Usenet alt.winsock.trumpet[153]): Version 2.0B[154] (no enforced limit on evaluation) WARNING: A bug in 2.0B can cause a system crash under certain rare conditions. Version 2.1F[155] (enforced 30-day limit on evaluation) WARNING: Earlier 2.1 versions have serious bugs and should not be used. WARNING: The author has found problems with streaming ZMODEM uploads in a telnet session over a Trumpet TCP/IP link. A work-around is to set a ZMODEM window size of 2 Kb. Mailer: Pegasus Mail for Windows[156] (Usenet bit.listserv.pmail[157]) Web browser: Netscape[158]; helper applications: Acrobat viewer: Adobe Acrobat Reader[159] QuickTime[160] video player Real-time audio: Real Audio Player[161] TIFF viewer: LView Pro[162] ZIP viewer: WinZip[163] Usenet newsreader: Free Agent[164] FTP (File Transfer Protocol): WS_FTP[165] Telnet (login to remote host): EWAN[166] Ping (is host alive): WS_PING[167] Finger (find user) and WhoIs (find host): WSFINGER[168] NSLookup (lookup DNS names): NSLookup[169] Set clock from network timeserver: Tardis[170] HTML editor: Microsoft Internet Assistant[171] (Word for Windows 6.0a or above required) Graphic Editor: Paint Shop Pro[172] Tranparent GIF converter: LView Pro[173] Sound Editor: Cool Edit[174] For more Winsock application information see: "Stroud's Consummate Winsock Apps List[175]" (files available at The Papa Winsock-L FTP Site[176]) "The Ultimate Collection of Winsock Software[177]" Usenet alt.winsock[178] You may be able to run dialup SLIP/PPP from a UNIX shell account with The Internet Adapter[179] (TIA). Even when your Internet Service Provider offers a SLIP/PPP option, it may be cheaper to run TIA from a shell account. TIA is commercial but inexpensive. A freeware alternative is SLiRP. For more information on TIA and SLiRP see "SLiRP/TIA and Trumpet Winsock Setup Reference[180]." (Usenet alt.dcom.slip-emulators[181]) Button[182] [Return to top[183]] ___________________________________ Any Trumpet Winsock tips? Where to get Trumpet Winsock: Version 2.0B[184] (no enforced limit on evaluation) WARNING: A bug in 2.0B can cause a system crash under certain rare conditions. Version 2.1F[185] (enforced 30-day limit on evaluation) WARNING: Earlier 2.1 versions have serious bugs and should not be used. WARNING: The author has found problems with streaming ZMODEM uploads in a telnet session over a Trumpet TCP/IP link. A work-around is to set a ZMODEM window size of 2 Kb. You can monitor Trumpet Winsock TCP/IP performance with TCPMeter. (Execute once Trumpet Winsock is running. Click the left and right mouse buttons to expand and contract the graph scale respectively, and try a scale of 4K or 8K for a 28.8 connection. Incoming speed graph bars point down; outgoing point up. Note that TCP/IP is a full duplex link where data can flow at full speed in both directions at the same time.) Here[186] for Trumpet Winsock 2.0 Included with Trumpet Winsock 2.1 (do not use the 2.0 version) Trumpet Winsock 2.0B locks an excessive amount of memory (107 Kb) below 1 Mb; 2.1F is improved, but still takes a substantial amount (44 Kb) of low memory. (See "Any other Windows tips?[187]") The amount of low memory is not affected by the TCP/IP settings. The following Trumpet Winsock script fragment will auto-redial (e.g., on BUSY), assuming that $number has been initialized with the number you want to dial: repeat sleep 2 # gives modem time to recover after connect failure outputecho "atdt"$number\r #dial number repeat read 90 $result # read modem response # wait for long response, ignoring normal intermediate responses until len($result) >= 4 & pos("~" + copy($result, 1, 4), "~RINGING~CARRI ER~PROTOCOL") = 0 until pos("CONNECT", $result) = 1 # retry if I did not connect The author recommends configuring your modem for Trumpet Winsock with &D1 rather than &D2; that way you can use DTR rather than the escape code to enter modem commands when online. The following Trumpet Winsock ATI6.CMD script can be used with a USR modem initialized with &D1 to display Link Diagnostics (e.g., the current modem-to-modem speed) when online: set dtr off # put modem in command mode (&D1) if [input 2 OK\n] # wait for modem response end set dtr on output at\r # make sure modem is alive if ! [input 1 OK\n] display \n"*** Modem is not responding!"\n abort end display \n"*** USR Link Diagnostics follow:"\n\n echo on output ati6\r if [input 5 OK\n] display \n"*** End of USR Link Diagnostics."\n\n end output ato\r # change to ATO1 to force a retrain input 15 CONNECT input 1 \n online # can probably get back online with SLIP, but not PPP The following Trumpet Winsock BYE.CMD script can be used to quickly disconnect your modem (configured with either &D1 or &D2): set dtr off # modem command mode (&D1) or disconnect (&D2) if [input 2 OK\n] # wait for modem response end set dtr on output athz\r # hangup command (&D1 or just to be sure with &D2) input 2 OK\n display "Disconnected." sleep 1 Button[188] [Return to top[189]] ___________________________________ Where can I get updated video drivers? [updated 4/11/96] Updated video drivers may help to correct CRC/overrun errors. (See "Why am I getting CRC errors (overruns)?[190]") Updated drivers are available at: AST Computer[191] ATI Technologies[192] Boca Research[193] Cirrus Logic[194] (generic) Compaq Computer[195] Dell Computer[196] Diamond Multimedia[197] Note: The author has experienced stability problems with various versions of Diamond drivers for both Windows 3.x and Windows 95, and recommends using Microsoft drivers (Windows 3.x[198]/Windows 95[199]/Windows NT[200]) or generic S3 drivers[201] if possible. [updated 4/11/96] Digital Equipment[202] Gateway 2000[203] Genoa Systems[204] Hercules[205] Hewlett Packard[206] IBM[207]: OS/2[208] Display drivers[209] Matrox[210] Microsoft[211]: Windows 3.x[212] Windows 95[213] [updated 4/9/96] Windows NT[214] Number Nine[215] Packard Bell[216] S3[217] (generic) [updated 3/29/96] STB Systems[218] Trident BBS: 415/691-1016 (generic) Tseng Labs BBS: 215/579-7536 (generic) Western Digital/Paradise[219] Note: Only those companies that have drivers available for download are listed. Button[220] [Return to top[221]] ___________________________________ Where can I get updated disk/SCSI drivers? [updated 4/9/96] Updated disk and/or SCSI drivers may help to correct CRC/overrun errors. (See "Why am I getting CRC errors (overruns)?[222]") Updated drivers are available at: Disk drives[223]: IOmega[224] Maxtor[225] Seagate[226] SyQuest Technology[227] Western Digital[228] IBM[229] OS/2[230]: Fixes and CSD's[231] "Other" drivers[232] IDE adapter/controller cards[233]: BusLogic[234] Promise Technology[235] Tekram Technology[236] (Recommended by the author) Microsoft[237]: Windows 95[238] [updated 4/9/96] Windows NT[239] SCSI adapter/controller cards[240]: Adaptec[241] (Recommended by the author) BusLogic[242] Promise Technology[243] QLogic[244] Tekram Technology[245] Note: Only those companies that have drivers available for download are listed. Button[246] [Return to top[247]] ___________________________________ Why 1024 bytes for the Windows COM buffer? The buffer size is mostly a flow control issue. When the buffer fills up above the "high water mark" (e.g., 75%), a Windows comm driver asserts receive flow control; then when it drops below the "low water mark" (e.g., 25%) a Windows comm driver releases receive flow control. (A Windows comm application should have nothing to do with flow control. DOS applications, on the other hand, do not use the Windows comm driver and so must do their own flow control.) For Windows applications then the only serious issue is that the size of the buffer between the "high water mark" and buffer-full must be big enough to give the local modem time to respond to flow control being asserted -- there is inevitably a certain amount of "dribble," but it's usually no more than about 10-20 characters, for which even the default 128-byte buffer should be adequate. For performance you want the buffer large enough for the Windows application to be able to process incoming data in reasonable sized chunks. (You also want the modem to respond to flow control being released before the buffer is drained by the application, although this is much less important due to modem buffering.) Thus if multitasking is going on, a somewhat larger buffer than the default (e.g., 256-1024) may improve performance. The higher end of the range accommodates a typical (YMODEM/ZMODEM) block. Beyond that point diminishing returns set in rapidly. For DOS applications the buffer size is more important, since the DOS application is responsible for flow control and takes much longer to respond than a Windows comm driver. That's why it's a good idea to have a receive buffer as big as a typical (YMODEM/ZMODEM) block (i.e., 1024 bytes). The alternative is to turn the buffer off completely and give the DOS application direct access to the COM port by setting a buffer size of 0. On the transmit side (where there's no flow control concern) the only consideration is performance -- you want the buffer to be big enough so that it doesn't drain to empty when the application is unable to respond fast enough to refill it. The default 128-byte buffer will drain in only 22 ms at 5760 cps, which is less than a single multitasking timeslice. A 1024-byte buffer takes 178 ms to drain, which is normally sufficient; above that point diminishing returns set in rapidly. One reason is that modem buffering can make up for (short) times that the transmit buffer drains to empty. And if you make the transmit buffer too large, it can introduce timing problems (due to the "long" buffer drain time) with DOS applications and with poorly written Windows applications. Button[248] [Return to top[249]] ___________________________________ What is "retraining"? What are "fall-back" and "fall-forward"? It's very important to properly distinguish between (a) retraining and (b) fall-back/forward. They are frequently confused but they are not the same thing. If you turn on the modem speaker with M2 you can easily hear the difference. RETRAINING Retraining is like the initial training -- several seconds where the modems probe the line in order to configure themselves (equalization, nonlinear coding, pre-emphasis, pre-coding, shaping, mapping, etc.). Either modem can request a retrain, but the retrain will only occur if the other modem grants it. You can hear the distinctive training sounds if the modem speaker is on. During the several seconds of retraining no data can flow. Because of that we want the modems to only retrain when truly necessary, as when line conditions have changed significantly and permanently, something that is usually rare. Retraining may not necessarily result in a higher speed. Excessive retrains can therefore be a serious problem. FALL-BACK/FORWARD Fall-back/forward is simple speed shifting that is relatively quick, so we would like the modems to fall back when needed to keep the error rate low, and fall forward when possible to improve throughput. With the modem speaker on you will hear only a small beep or blip in the carrier hiss. If a noise burst causes a fall-back, we want the modems to fall-forward as soon as the burst is gone. What we don't want is for the modems to ping-pong back and forth between two speeds, because that would result in lower throughput than simply remaining at the lower speed. Again, fall-back/forward can be requested by either modem, but will only occur if the other modem permits it. Button[250] [Return to top[251]] ___________________________________ How do I set a speed greater than 19200 bps in Windows? You can set a speed faster than 19200 in the Windows Control Panel by simply typing it in. However, there is almost never a need to do so -- almost all Windows comm applications set their own serial port speed. The settings in the Control Panel are primarily for devices attached to the serial port; e.g., printers. (See "Control Panel Serial Port Settings Are for Printing Only[252]") Button[253] [Return to top[254]] ___________________________________ What about third-party comm drivers for Windows? Despite "urban legends" to the contrary, the standard Windows 3.1 COMM.DRV is capable of supporting high-speed modems on a reasonably fast system, and does support the 16550 FIFO. (See "Windows Support of the 16550 UART[255]") However, it does have three limitations: It does not use the transmit FIFO. This rarely makes any difference for data, but can be a problem for Class 1 fax timing above 9,600 bps. The receive FIFO threshold is fixed at 14 bytes, which leaves only 2 bytes before overrun occurs. Dropping the receive threshold to 8 bytes (or even lower) may help to reduce overruns. For that you need a third-party comm driver. DOS comm programs running under Windows 386 Enhanced Mode are fooled into thinking that the COM port only has a 16450 UART. This can cause problems, particularly with poorly-written DOS comm programs (i.e., those that do not drain the UART buffer on each receive interrupt). The alternative is to give the DOS application direct access to the COM port (see "Why 1024 bytes for the Windows COM buffer?[256]") or, better yet, upgrade to Windows for Workgroups 3.11 or Windows 95. Also despite "urban legends" to the contrary, COMM.DRV supports speeds up to 256,000 bps, hardware permitting, including 115,200 bps. (See "Setting Baud Rates in Windows 3.1[257]") How fast you can go will depend on your hardware. With only an 8250 or 16450 UART, you may not be able to go faster than 19,200 bps without overrun; with a 16550 UART and a reasonably fast system, you should be able to go up to 57,600 bps, or even 115,200 bps. 57,600 bps is normally adequate for even a 28,800 bps modem. Caveat: With an acknowledgment protocol (e.g., XMODEM), as opposed to a streaming protocol (e.g., ZMODEM), a higher serial port speed can improve the response time. Third-party comm drivers include the freeware: CYBERCOM.DRV[258] WFXCOMM.DRV[259] (from Delrina[260], particularly recommended f or use with WinFax) Third-party drivers are not needed for and should not be used with Windows for Workgroups 3.11 or Windows 95, which have a better comm architecture than standard Windows. An upgrade to Windows for Workgroups 3.11 or Windows 95 is probably the best way to improve Windows communications. (See "Any other Windows tips?[261]") Third-party Windows drivers should also not be used with OS/2 (Warp). Button[262] [Return to top[263]] ___________________________________ How can I share a modem between data and WinFax? Delrina WinComm PRO can seamlessly share a modem with Delrina WinFax PRO. With WinFax PRO set to automatically answer the telephone, WinComm PRO will turn off WinFax PRO auto-answer to dial out, and turn WinFax PRO auto-answer back on when it is through with the modem. The two programs may be purchased together in a discounted bundle called the Delrina Comm Suite. With other data comm programs you can use WfListen[264], a program that will shut down Delrina WinFax when you start your data comm program, and then restart WinFax when you shut down your data comm program, all automatically. Shareware. (A companion program, wfStatus[265], modifies the WinFax icon to show whether it's ready to receive faxes or not. Also shareware.) Another alternative is KingComm, a commercial virtual comm port driver that allows multiple comm apps to share the same modem. Multi-Tech[266] provides a proprietary "Virtual Modem" comm driver for Windows with certain modems that will reportedly route incoming data and fax calls to appropriate applications. However, it does not support the 16550 FIFO buffers, a serious drawback. (See "Do I need a 16550 UART? What is a UART?[267]") Note: Except for Multi-Tech, these alternatives do not have the ability to automatically detect and properly route incoming data and fax calls. For that you need a modem that supports incoming Call Discrimination (also called "Adaptive Answer" or "Call Select"), as well as data and fax comm software which support that capability (e.g., WinFax PRO 7.0 for Windows 95[268] [see "How can I use a single phone for fax/data/voice?[269]"] or Procomm Plus for Windows 2.xx[270]). Button[271] [Return to top[272]] ___________________________________ How can I display the status of an internal modem under Windows? ModemSta[273] displays an animated icon replica or larger indicator displays of modem's front panel. Several 3D looks, with customizable colors. For use with internal, external and PCMCIA modems. Modem initialization, logging of incoming calls and connections, additional status info, show communications settings, generation of sounds at comm events. Can also monitor parallel ports. Shareware US$15. Note: It is not possible to continuously display the modem-to-modem speed of an internal modem. (Some drivers and applications display data throughput, but that is not the same thing.) The reason is that you have to have to escape the modem to command mode and issue a special command, if available, which interrupts the flow of data. (See "Any other USRobotics tips?[274]") Button[275] [Return to top[276]] ___________________________________ Why does Windows lock up when I access my modem? The most common cause of this problem is a 16550-compatible chip that isn't fully compatible. Typically this is seen on Pentium systems with serial ports integrated on the motherboard, but it can also happen with add-on cards, particularly "multi-I/O" cards based on popular SMC[277] chips. (See "PC Hangs While Running a Communications Application[278]" and "16550 UART FIFO Support under Windows NT[279]") Updated drivers are available from SMC and Microsoft to work around the problem. The SMC package[280] includes both SMC's updated COMM.DRV for regular Windows 3.1 and Microsoft's updated SERIAL.386 for Windows for Workgroups 3.11; the Microsoft package[281] includes only Microsoft's updated SERIAL.386 (10,620 bytes dated 2/17/94). But see warning below. Alternatively you should be able to completely solve (or simply test) the problem by turning off the UART FIFO buffers. To do that under regular Windows 3.1 or Windows for Workgroups 3.11, put the following in the [386Enh] section of your SYSTEM.INI file: COMnFIFO=0 where n is the number of your modem COM port (e.g., COM2FIFO=0). Under Windows NT see "16550 UART FIFO Support under Windows NT[282]." The drawback is that you then won't get the benefit of the 16550 FIFO buffers. (See "Do I need a 16550 UART? What is a UART?[283]") Warning: Although Microsoft specifically identifies the SMC '665 chip as the problem, the author has personally verified that a problem also exists in the SMC '666 chip (FDC37C666GT). Furthermore, although the original FIFO problem is reportedly fixed in current chip production, the author has personally verified that a problem (perhaps a different problem) still exists as of August 1995. The author has also personally verified that: SMC's updated COMM.DRV does not correct this current problem; and Microsoft's updated SERIAL.386 is not fully satisfactory: lockups are very rare but not entirely eliminated, and Windows multitasking is adversely affected during certain communications operations (e.g., negotiating a dialup PPP link with Trumpet Winsock 2.1F[284]). The only fully effective workaround is to disable the FIFO buffers (as described above). For this reason the author does not currently recommend products that use SMC "multi-I/O" chips. Button[285] [Return to top[286]] ___________________________________ Why can't I get back on-line after I escape to command mode? While on-line you escape your modem to command mode with "+++", and then try to get back into data mode with ATO, but the remote system no longer responds. You have to break the connection to recover. What's probably happening is that your "+++" escape code is being echoed by the remote system back to the remote modem, throwing it into command mode as well, a state from which you cannot recover short of disconnecting. It really shouldn't be happening, because any BBS SYSOP or Internet Provider worthy of the name should either disable the escape sequence or at least change it to an unusual value. But all too many don't. The solution is to use modem register S2 to change your modem escape character. The author uses S2=61 to change the escape character to "=", which is on the same key as "+", making it easy to remember. Button[287] [Return to top[288]] ___________________________________ What are the best (data/fax) comm programs for Windows? There are several excellent programs, and what is best for one won't necessarily be best for others. For data comm, the personal favorites of the author are HyperACCESS for Windows (commercial from Hilgraeve[289]) and the near-clone WinComm PRO (commercial from Delrina[290]). Both are extremely powerful while being very easy to use. For those on a budget, there is a freeware version of WinComm called WinComm Lite[291]. (There is also a freeware DOS comm program from Delrina called FreeComm[292]. Neither WinComm Lite nor FreeComm has been reviewed by the author.) Popular shareware alternatives include: Softerm Plus[293] (X/Y/ZMODEM with SLIP and TCP/IP) Telix for Windows[294] UniCom[295] WinQVT[296] (VT-220 emulator with X/Y/ZMODEM/Kermit) WinRamp Lite[297] (w/RIP) For fax comm, the personal favorite of the author is WinFax PRO (commercial from Delrina[298]). It integrates well with WinComm PRO, and the two can be purchased in a discounted bundle as the Delrina Comm Suite. (If you experience fax problems with a USR modem, see "Any other USRobotics tips?[299]") Note: Delrina[300] has been acquired by Symantec[301]. The author does not recommend Version 2.xx of Procomm Plus for Windows (commercial from Datastorm[302]). While version 1.xx evolved into a robust (albeit quirky) data comm program, version 2.xx has suffered from "featuritis" and has been plagued with many problems (e.g., greatly excessive locking of memory below 1 Mb [See "PRB: Avoiding 'Insufficient Memory to Run' Errors[303]"]). Button[304] [Return to top[305]] ___________________________________ Why do I sometimes have problems connecting? See below and also "Any other USR tips?[306]". Why do I sometimes get abruptly disconnected? Disconnections may be caused by momentary drops of DTR by certain comm applications. (By default most modems respond to a drop of DTR by hanging up.) With most modems you can work around this problem by disabling DTR (i.e., &D0). Note that when DTR is disabled you have to escape the modem to command mode and use the "ATH" command to hang up. With USR modems you can also use register S25 to work around the problem (e.g., S25=10 will ignore a DTR drop of less than 10/100 or 1/10 second, which is twice the default of 5/100 second). For those experiencing disconnects (and/or erratic connection speeds) when calling Rockwell-based V.FC modems from a USR 28800 (V.FC or V.34) modem, a firmware fix is now available for the Sportster (dated 4/18/95 or later for USA modems) by calling USR (708-982-5151); for the Courier, the fix (dated 7/5/95 or later for USA modems) is available by FTP[307]. In the meantime, the author's workarounds (which may help in some cases even if you have the updated firmware) are: Disable V.42 Detect Phase (i.e., S27=48). -- or -- Disable V.42 completely (i.e., S27=32). If you then sometimes get non-error-correcting connections, force error-correction mode (i.e., &M5). You may find that you have to redial several times to get connected; if so, try the following. -- and/or --- Disable the highest symbol rates (e.g., S54.5=1S54.4=1S54.3=1). This will limit your top speed (to 24000 in this example), depending on how many symbol rates you disable (3429, 3200, and 3000 in this example). -- also -- With V.FC-only firmware (as opposed to the newer V.34 firmware) it may help to also disable the 32S-2D map (i.e., S55.2=1). -- finally -- It may also help to set S10=255. With a USR 28800 modem, you can determine the technical reason for a disconnect by issuing the ATI6 command immediately after the disconnection. If possible, set these options on a phone number-specific basis. With comm apps which lack that capability, you may be able to embed them in the phone number; e.g., "^H^HS27=48DT555-1212". (The two "^H" backspace characters erase the "DT" in an "ATDT" dial command so that the "S27=48" will be accepted, and then the following "DT" replaces the "DT" that was erased; i.e., "ATDT" + "^H^HS27=48DT555-1212" = "ATS27=48DT555-1212".) Button[308] [Return to top[309]] ___________________________________ <<cont>>